Systems and methods for user authentication based on multiple devices

ABSTRACT

A user may be authenticated using an authentication scheme based on user access to two or more selected electronic devices. A security key may be assigned to the user. The security key is divided into multiple parts that are distributed among electronic devices associated with the user. The security key can be reconstructed based on a distributed trust among the devices, where some devices may have a higher trust level than others. For example, each device can receive a number of key parts. In response to a request to authenticate the user, parts of the security key may be retrieved from two or more, but less than all, of the plurality of electronic devices associated with the user. The retrieved parts are used to reconstruct the security key, and the user is authenticated based on the reconstructed security key.

CROSS-REFERENCE TO RELATED APPLICATION

The present application is a continuation of U.S. patent applicationSer. No. 16/007,957, filed Jun. 13, 2018, all of which is incorporatedby reference herein in its entirety.

BACKGROUND

The present specification generally relates to user authentication, andmore specifically, to authenticating a user based on a variable trustschema involving security keys and electronic devices accessible by theuser according to various embodiments of the disclosure.

RELATED ART

As the ability to access personal information and perform onlinetransactions grows, the need for secure, yet convenient, ways toauthenticate a user rises. Conventional authentication that involves auser name and password has been proven to be both insecure andinconvenient in various aspects, as this technique relies on the user toselect a strong password and to keep the password safe from malicioususers. Biometric-based authentication techniques, such as fingerprintscan, iris scan, facial recognition, etc., may require additionalhardware and/or additional steps performed by the user to collect thebiometric data. Similarly, while authentication based on a smart cardcan be more secure than simply providing a user name and a password, italso requires additional hardware (e.g., a smart card reader) foraccepting the smart card. Thus, there is a need for providing animproved authentication system that is both secure and convenient.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 is a block diagram illustrating an electronic transaction systemaccording to an embodiment of the present disclosure;

FIG. 2 is a block diagram illustrating an authentication systemaccording to an embodiment of the present disclosure;

FIG. 3 is a flowchart showing a process of registering a user with anauthentication system according to an embodiment of the presentdisclosure;

FIG. 4 is a block diagram illustrating an authentication systemaccording to an embodiment of the present disclosure;

FIG. 5 is a flowchart showing a process of authenticating a useraccording to an embodiment of the present disclosure; and

FIG. 6 is a block diagram of a system for implementing a deviceaccording to an embodiment of the present disclosure.

Embodiments of the present disclosure and their advantages are bestunderstood by referring to the detailed description that follows. Itshould be appreciated that like reference numerals are used to identifylike elements illustrated in one or more of the figures, whereinshowings therein are for purposes of illustrating embodiments of thepresent disclosure and not for purposes of limiting the same.

DETAILED DESCRIPTION

The present disclosure describes methods and systems for authenticatinga user based on an accessibility of a user device associated with theuser to access two or more selected electronic devices. As networkedelectronic devices become more prevalent, a user may have access tomultiple electronic devices at any given situation, via the user device(e.g., a mobile device) of the user. For example, when the user is athome, the user may access, via the user device, one or more of a homecomputer, a smart television, a smart speaker, a networked refrigerator,a networked light switch, a networked thermostat, or other smartappliances. The user device may be communicatively coupled with thesedifferent electronic devices via different networks. For example, theuser device may be communicatively coupled with the home computer via ahome Wi-Fi network. The user device may be communicatively coupled withthe smart speaker via a Bluetooth connection. The user device may becommunicatively coupled with the smart television via an infraredconnection. The user device may be communicatively coupled with smartappliances such as the networked refrigerator, the networked lightswitch, and the networked thermostat via a Zigbee network or any othernetwork protocols.

Similarly, when the user is away from home, the user may use the userdevice to access an in-vehicle management system of a vehicle (e.g., viaa Bluetooth connection, etc.), a home security system (e.g., via an IPconnection), a smart watch that the user is wearing (e.g., via aBluetooth connection), a pair of smart glasses that the user is wearing(e.g., via a Bluetooth connection), a chip on a pair of shoes (e.g., viaa near field communication (NFC) connection), a chip on a briefcase,(e.g., via a radio frequency identification connection), etc. When theuser is at work, the user may use the user device to access one or moreof a work computer (e.g., via the work Wi-Fi network), a smart speakerat work (e.g., via a Bluetooth connection), an external screen (e.g.,via an infrared connection), or other electronics in the office. Assuch, the user may have access to different electronic devices based ona location of the user and/or an activity in which the user engages.Note that the communication protocols and devices listed above aremerely examples, and other protocols and/or devices may be used invarious embodiments.

Thus, an authentication system may authenticate the user based on theuser's ability to access two or more of the electronic devicesassociated with the user. Notably, as explained below, these variousdevices may be associated with a particular level of trust, e.g.,certain devices may have higher trust levels than other devices (as itmay be harder to “hack” certain types of devices vs. others). Duringregistration of the user with the authentication system, theauthentication system may obtain identities of the electronic devicesaccessible by the user. In some embodiments, for each of the electronicdevices, the authentication system may also obtain a network protocolthrough which the electronic device may be communicated with, and anetwork address.

Furthermore, the authentication system may assign one or more securitykeys to the user for authenticating the user. A security key that isassigned to the user may be divided into a number of different parts. Insome embodiments, the security key may be divided in a manner such thatthe security key may be reconstructed based on less than the totalnumber of divided parts. For example, the security key may be dividedinto a total of nine parts, but any four out of the nine parts may besufficient to reconstruct the security key for authenticating the user.

In some embodiments, the different parts may be distributed among theelectronic devices that are accessible by the user, for example, via theuser device of the user. One or more parts of the security key may betransmitted to each of the electronic devices accessible by the userbased on the network protocols and the network addresses associated withthe electronic devices according to a distribution scheme. The parts maythen be stored in non-transitory data storages (e.g., a random accessmemory storage, a flash drive, etc.) of the electronic devices.

Different embodiments may use different techniques to determine adistribution scheme for distributing the parts among the electronicdevices. In some embodiments, the authentication system may determinethe distribution scheme based on trust scores associated with theelectronic devices. For example, when information regarding theelectronic devices is obtained, the authentication system may analyzethe devices to determine the trust scores for the devices. The trustscores may be determined for the devices based on a security profile ofthe devices. For example, the authentication system may obtain asecurity rating for each of the devices and determine a trust score forthe device based on the security rating. In some embodiments, theauthentication system may access each of the electronic devices (e.g.,via the user device), to analyze the hardware configuration (e.g.,whether the hardware includes any security modules), the softwareconfiguration (e.g., whether the software includes any security modules,whether any security patches are installed, etc.), and a location (e.g.,whether the device is fixed at a location) of the device. Theauthentication system may determine and/or update the trust score of adevice based on the analysis of the hardware configuration, the softwareconfiguration, and/or the location of the device, and may determine thedistribution scheme based on the trust scores of the devices. Forexample, the distribution scheme may provide a device having a highertrust score (based on the hardware configuration, the softwareconfiguration, and/or the location) with a larger number of parts whileproviding another device having a lower trust score (based on thehardware configuration, the software configuration, and/or the location)with a lower number of parts. Thus, different devices with differenttrust levels may be assigned greater or lesser influence (via the numberof distributed key parts assigned to them) in authentication schemesdiscussed herein.

In some embodiments, the authentication system may then distribute theparts of the security key among the electronic devices according to thedetermined distribution scheme. For example, when the security key isdivided into nine parts, the authentication system may distribute threeparts to the smart television (since the smart television is fixed at alocation and can only be connected via an infrared connection whichrequires a line of sight from a connecting device), one part to the chipof the briefcase (since the briefcase can be located in public areas,can be easily stolen, etc.), two parts to the work computer (since thework computer should be physically located in a safe area), and soforth. Various factors may dictate the particular key part assignmentsin different embodiments.

A request for authenticating the user may be received via the userdevice, for example, when the user attempts to log in to a user accountof a service provider on the user device or when the user attempts toperform an electronic transaction using the user device. For example, anauthentication request can be generated in association with a userlogging into a PayPal™ account, or another electronic account. Uponreceiving the request, the authentication system may select some, butnot all, of the electronic devices for authenticating the user.

In some embodiments, when the authentication system obtains informationrelated to the electronic devices, the authentication system maygenerate and/or associate different profiles with the electronicdevices. In one example, the authentication system may generate a homeprofile, a work profile, and a commuting profile. Each of the electronicdevices may be associated with one or more profiles based on a locationand/or a situation in which the user may access the electronic devices.For example, the home computer, the smart television, the networkedrefrigerator, the networked light switch, and the networked thermostatmay be associated with the home profile. The smart watch and the smartglasses may be associated with all of the home profile, the workprofile, and the commuting profile. The in-vehicle management system ofthe vehicle may be associated with a commuting profile. The chip on theshoes and the chip on the briefcase may be associated with both thecommuting profile and the work profile. The work computer, the externalscreen in the office, the smart speaker at work, and the otherelectronics in the office may be associated with the work profile. Otherprofile types may be used in various embodiments.

As such, the authentication system may first determine a location and/oractivity of the user and select the electronic devices associated withthe corresponding profile based on the determined location and/oractivity. For example, when the authentication system determines thatthe user is at home, the authentication system may select electronicdevices that are associated with the home profile. Similarly, when theauthentication system determines that the user is commuting, theauthentication system may select electronic devices that are associatedwith the commuting profile, and when the authentication systemdetermines that the user is at work, the authentication system mayselect electronic devices that are associated with the work profile. Insome embodiments, however, the authentication system may randomly selectthe two or more electronic devices from the electronic devicesassociated with the user.

Furthermore, the authentication system may select a sufficient number ofelectronic devices such that the total number of parts distributed tothe selected electronic devices are sufficient to reconstruct thesecurity key. In some embodiments, the authentication system may selectthe electronic devices such that at least two electronic devices requiretwo different types of network connections (e.g., different networkprotocols) to be accessed to enhance the security and the effectivenessof the authentication system.

The authentication system may then access the selected electronicdevices via the user device, retrieve the parts from the selectedelectronic devices, and reconstruct the security key based on theretrieved parts. The authentication system may authenticate the userbased on the reconstructed security keys. For example, when all of theselected electronic devices are accessible via the user device, and thusall of the parts that are distributed to the selected electronic devicesare retrieved, the reconstructed security key should match the originalsecurity key assigned to the user. On the other hand, when less than therequired number of parts are retrieved to reconstruct the security key(e.g., when one or more of the selected electronic devices are notaccessible via the user device), the reconstructed security key wouldnot match the original security key assigned to the user. Thus, theauthentication system may authenticate the user based on thereconstructed security key, and more particularly, based on whether thereconstructed security key matches the original security key assigned tothe user.

In some embodiments, the authentication system may update the trustscores of the electronic devices based on new information regarding thesecurity risks of the electronic devices. For example, when theauthentication system accesses the selected electronic devices toretrieve the parts, the authentication system may analyze the softwareconfiguration of the electronic devices. When it is determined that thesoftware (e.g., the operating system) of the electronic device isupdated, the authentication system may increase the trust score of theelectronic device. On the other hand, when a new security module/updateis available to the electronic device, but is determined to be notinstalled on the device, the authentication system may reduce the trustscore of the electronic device. Based on the updated trust scores of theelectronic devices, the authentication system may update thedistribution scheme. In some embodiments, the authentication system mayremove one or more parts from an electronic device based on the updatedtrust score of the electronic device. The authentication system may alsoadd one or more parts to an electronic device based on the updated trustscore of the electronic device.

In some embodiments, more than one security key may be assigned to theuser. The different security keys may be divided into parts differentlysuch that for different security keys, different numbers of parts arerequired to reconstruct the corresponding security keys. Further, thedifferent security keys may correspond to different risk levels, suchthat a security key that requires a higher number of parts to bereconstructed may correspond to a higher risk level than a security keythat requires a lower number of parts to be reconstructed. For example,a first security key that requires two of the nine divided parts to bereconstructed may correspond to a low risk level, a second security keythat requires four of the nine divided parts to be reconstructed maycorrespond to a medium risk level, and a third security key thatrequires six of the nine divided parts to be reconstructed maycorrespond to a high risk level. The parts of the different securitykeys may be distributed among the electronic devices according to thesame distribution scheme or different distribution schemes.

Thus, upon receiving the request to authenticate the user, theauthentication system may first determine a risk level associated withthe request. For example, when the request is a request to login to auser account, the authentication system may determine the risk levelbased on a location of the user (e.g., whether the user is located at alocation that is normally associated with the user). When the request isa request to perform an electronic payment transaction, theauthentication system may determine the risk level based on an amountassociated with the transaction (e.g., a high risk level when the amountexceeds a predetermined threshold, a low risk level when the amount isbelow another predetermined threshold, etc.). The authentication systemmay then select one of the security keys assigned to the user based onthe determined risk level of the request and retrieve the parts from theselected electronic devices that correspond to the selected securitykey. As discussed above, the authentication system may reconstruct thesecurity key based on the retrieved parts, and authenticate the userbased on the reconstructed security key.

FIG. 1 illustrates an electronic transaction system 100 in which theauthentication system may be implemented according to one embodiment ofthe disclosure. The electronic transaction system 100 includes a serviceprovider server 130, a merchant server 120, and a user device 110 thatmay be communicatively coupled with each other via a network 160. Thenetwork 160, in one embodiment, may be implemented as a single networkor a combination of multiple networks. For example, in variousembodiments, the network 160 may include the Internet and/or one or moreintranets, landline networks, wireless networks, and/or otherappropriate types of communication networks. In another example, thenetwork 160 may comprise a wireless telecommunications network (e.g.,cellular phone network) adapted to communicate with other communicationnetworks, such as the Internet.

The user device 110, in one embodiment, may be utilized by a user 140 tointeract with the merchant server 120 and/or the service provider server130 over the network 160. For example, the user 140 may use the userdevice 110 to log in to a user account to conduct account services orconduct various electronic transactions (e.g., electronic paymenttransactions, etc.) with the service provider server 130. Similarly, amerchant associated with the merchant server 120 may use the merchantserver 120 to log in to a merchant account to conduct account servicesor conduct various electronic transactions (e.g., electronic fundstransactions, etc.) with the service provider server 130. The userdevice 110, in various embodiments, may be implemented using anyappropriate combination of hardware and/or software configured for wiredand/or wireless communication over the network 160. In variousimplementations, the user device 110 may include at least one of theuser devices described herein, such as a wireless cellular phone,wearable computing device, PC, laptop, etc.

The user device 110, in one embodiment, includes a user interface (UI)application 112 (e.g., a web browser), which may be utilized by the user140 to conduct electronic transactions (e.g., shopping, purchasing,bidding, etc.) with the service provider server 130 over the network160. In one aspect, purchase expenses may be directly and/orautomatically debited from an account related to the user 140 via theuser interface application 112.

In one implementation, the user interface application 112 includes asoftware program, such as a graphical user interface (GUI), executableby a processor that is configured to interface and communicate with theservice provider server 130 via the network 160. In anotherimplementation, the user interface application 112 includes a browsermodule that provides a network interface to browse information availableover the network 160. For example, the user interface application 112may be implemented, in part, as a web browser to view informationavailable over the network 160.

The user device 110, in various embodiments, may include anauthentication application 116 that implements at least some of theauthentication functionalities disclosed herein. For example, duringregistration of the user 140 to the authentication system, theauthentication application 116 may provide an interface to the user 140to obtain information related to electronic devices associated with theuser 140, the network protocols and network addresses associated withthe electronic devices, and to set up one or more profiles for theelectronic devices. The authentication application 116 may alsodistribute parts of one or more security keys assigned to the user 140to the electronic devices.

In some embodiments, the authentication application 116 may becommunicatively coupled with and/or integrated with the user interfaceapplication 112 to detect when a request to authenticate the user 140 isreceived. For example, the authentication application 116 may receive arequest to authenticate the user 140 when the user 140 is logging in toa user account with the service provider server 130 or perform anelectronic transaction with the user account via the user interfaceapplication 112. When the request to authenticate the user 140 isreceived, the authentication application 116 may retrieve parts from oneor more electronic devices based on the request to authenticate the user140. In some embodiments, the authentication application 116 mayreconstruct the security key based on the retrieved parts, andauthenticate the user 140 based on the reconstructed key.

The user device 110, in one embodiment, may include at least oneidentifier 114, which may be implemented, for example, as operatingsystem registry entries, cookies associated with the user interfaceapplication 112, identifiers associated with hardware of the user device110 (e.g., a media control access (MAC) address), or various otherappropriate identifiers. The identifier 114 may include one or moreattributes related to the user 140 of the user device 110, such aspersonal information related to the user (e.g., one or more user names,passwords, photograph images, biometric IDs, addresses, phone numbers,social security number, etc.) and banking information and/or fundingsources (e.g., one or more banking institutions, credit card issuers,user account numbers, security data and information, etc.). In variousimplementations, the identifier 114 may be passed with a user loginrequest to the service provider server 130 via the network 160, and theidentifier 114 may be used by the service provider server 130 toassociate the user with a particular user account maintained by theservice provider server 130.

In various implementations, the user 140 is able to input data andinformation into an input component (e.g., a keyboard) of the userdevice 110 to provide user information with a transaction request, suchas a login request, a fund transfer request, a request for adding anadditional funding source (e.g., a new credit card), or other types ofrequest. The user information may include user identificationinformation.

The user device 110, in various embodiments, includes a locationcomponent 118 configured to determine, track, monitor, and/or provide aninstant geographical location of the user device 110. In oneimplementation, the geographical location may include GPS coordinates,zip-code information, area-code information, street address information,and/or various other generally known types of location information. Inone example, the location information may be directly entered into theuser device 110 by the user via a user input component, such as akeyboard, touch display, and/or voice recognition microphone. In anotherexample, the location information may be automatically obtained and/orprovided by the user device 110 via an internal or external monitoringcomponent that utilizes a global positioning system (GPS), which usessatellite-based positioning, and/or assisted GPS (A-GPS), which usescell tower information to improve reliability and accuracy of GPS-basedpositioning. In other embodiments, the location information may beautomatically obtained without the use of GPS. In some instances, cellsignals or wireless signals are used. For example, location informationmay be obtained by checking in using the user device 110 via a check-indevice at a location, such as a beacon. This helps to save battery lifeand to allow for better indoor location where GPS typically does notwork.

Even though only one user device 110 is shown in FIG. 1, it has beencontemplated that one or more user devices (each similar to user device110) may be communicatively coupled with the service provider server 130via the network 160 within the system 100.

The merchant server 120, in various embodiments, may be maintained by abusiness entity (or in some cases, by a partner of a business entitythat processes transactions on behalf of business entity). Examples ofbusiness entities include merchant sites, resource information sites,utility sites, real estate management sites, social networking sites,etc., which offer various items for purchase and process payments forthe purchases. The merchant server 120 may include a merchant database124 for identifying available items, which may be made available to theuser device 110 for viewing and purchase by the user.

The merchant server 122, in one embodiment, may include a marketplaceapplication 122, which may be configured to provide information over thenetwork 160 to the user interface application 112 of the user device110. For example, the user 140 of the user device 110 may interact withthe marketplace application 122 through the user interface application112 over the network 160 to search and view various items available forpurchase in the merchant database 124.

The merchant server 120, in one embodiment, may include at least onemerchant identifier 126, which may be included as part of the one ormore items made available for purchase so that, e.g., particular itemsare associated with the particular merchants. In one implementation, themerchant identifier 126 may include one or more attributes and/orparameters related to the merchant, such as business and bankinginformation. The merchant identifier 126 may include attributes relatedto the merchant server 120, such as identification information (e.g., aserial number, a location address, GPS coordinates, a networkidentification number, etc.).

A merchant may also use the merchant server 120 to communicate with theservice provider server 130 over the network 160. For example, themerchant may use the merchant server 120 to communicate with the serviceprovider server 130 in the course of providing various electronicservices offered by the service provider to a merchant, such asproviding an online platform that facilitates electronic payment betweencustomers of the merchant and the merchant itself. For example, themerchant server 120 may use an application programming interface (API)that allows it to offer sale of goods or services in which customers areallowed to make electronic payments through the service provider server130, while the user 140 may have an account with the service providerserver 130 that allows the user 140 to use the service provider server130 for making electronic payments to merchants that allow use ofauthentication, authorization, and electronic payment services of theservice provider. The merchant may also have an account with the serviceprovider server 130. Even though only one merchant server 120 is shownin FIG. 1, it has been contemplated that one or more merchant servers(each similar to merchant server 120) may be communicatively coupledwith the service provider server 130 and the user device 110 via thenetwork 160 in the system 100.

The service provider server 130, in one embodiment, may be maintained bya transaction processing entity or an online service provider, which mayprovide processing for electronic transactions between the user 140 ofuser device 110 and one or more merchants. As such, the service providerserver 130 may include a service application 138, which may be adaptedto interact with the user device 110 and/or the merchant server 120 overthe network 160 to facilitate the electronic transactions such aslogging in to a user account, electronic payment transactions,onboarding transactions, and/or other electronic services offered by theservice provider server 130. In one example, the service provider server130 may be provided by PayPal®, Inc. of San Jose, Calif., USA, and/orone or more service entities or a respective intermediary that mayprovide multiple point of sale devices at various locations tofacilitate transaction routings between merchants and, for example,service entities.

In some embodiments, the service application 138 may include a paymentprocessing application (not shown) for processing purchases and/orpayments for electronic transactions between a user and a merchant orbetween any two entities. In one implementation, the payment processingapplication assists with resolving electronic transactions throughvalidation, delivery, and settlement. As such, the payment processingapplication settles indebtedness between a user and a merchant, whereinaccounts may be directly and/or automatically debited and/or credited ofmonetary funds in a manner as accepted by the banking industry.

The service provider server 130 may also include a web server 134 thatis configured to serve web content to users in response to HTTPrequests. As such, the web server 134 may include pre-generated webcontent ready to be served to users. For example, the web server 134 maystore a log-in page, and is configured to serve the log-in page to usersfor logging into user accounts of the users to access various serviceprovided by the service provider server 130. The web server 134 may alsoinclude other webpages associated with the different electronic servicesoffered by the service provider server 130. As a result, a user mayaccess a user account associated with the user and access variousservices offered by the service provider server 130, by generating HTTPrequests directed at the service provider server 130.

In various embodiments, the service provider server includes anauthentication module 132 that is configured to authenticate the user140 based on the accessibility of the user device 110 to two or more ofthe electronic devices registered under the user account of the user 140according to various embodiments of the disclosure. In some embodiments,the authentication module 132 may generate one or more security keys forthe user 140, and divide the security keys into multiple parts. Theauthentication module 132 may also distribute the parts to theelectronic devices associated with the user 140 via the authenticationapplication 116 according to a distribution scheme.

The authentication module 132 may receive an authentication request. Forexample, the authentication request may be received from the web server132 when the web server 132 receives a request to log into a useraccount from the user interface application 112 of the user device 110.The request may be received from the service application 138 when theservice application 138 receives a request to perform one or moreelectronic transactions with the service provider server 130 from theuser device 110. The request may also be received from the marketplaceapplication 122 of the merchant server 120 when the user 140 performs anonline purchase transaction with the merchant server 120. Upon receivingthe authentication request, the authentication module 132 may select twoor more of the electronic devices associated with the user 140, andretrieve parts from the selected two or more electronic devices via theauthentication application 116. The authentication module 132 mayreconstruct the security key based on the parts retrieved via theauthentication application 116, and authenticate the user 140 based onthe reconstructed security key. In some embodiments, the authenticationmodule 132 and the authentication application 116 are part of theauthentication system that can provide the authenticationfunctionalities as disclosed herein as a standalone application or beintegrated with one or more services, such as ones associated with theservice provider server 130 as illustrated herein.

The service provider server 130, in one embodiment, may be configured tomaintain one or more user accounts and merchant accounts in an accountdatabase 136, each of which may include account information associatedwith one or more individual users (e.g., the user 140 associated withuser device 110) and merchants. For example, account information mayinclude information related to the electronic devices associated with acorresponding user account (e.g., identities of the electronic devices,the network protocols and the network addresses of the electronicdevices, etc.), private financial information of users and merchants,which may be used by the authentication module 132 to authenticateusers. In certain embodiments, account information also includes userpurchase profile information such as account funding options and paymentoptions associated with the user, payment information, receipts, andother information collected in response to completed funding and/orpayment transactions.

FIG. 2 illustrates an authentication system 200 according to oneembodiment of the disclosure. The authentication system 200 includes anauthentication application 216, an authentication module 232, a database202, and electronic devices including a networked light switch 242, anin-vehicle management system 244 of a vehicle of the user 140, a smarthome entertainment system 246, a networked refrigerator 248, and a smartwatch 250. The authentication application 216 may correspond to theauthentication application 116 of the user device 110, and theauthentication module 232 may correspond to the authentication module132 of the service provider server 130. The electronic devices 242-250may be connected and accessed by the user device 110 via differentnetwork protocols. For example, the networked light switch 242 may beconnected via a Zigbee connection, the in-vehicle management system 244may be connected via a Bluetooth connection, the smart homeentertainment system 246 may be connected via a wireless infraredcommunication connection, the networked refrigerator 248 may beconnected via a Wi-Fi connection using the Internet Protocol (IP), andthe smart watch 250 may be connected via a Bluetooth connection.

FIG. 3 illustrates a process 300 for registering a user to theauthentication system 200 according to an embodiment of the disclosure.In some embodiments, the process 300 may be performed by theauthentication system 200. The process 300 begins by generating (at step305) a security key for a user account. For example, the authenticationapplication 216 may provide a user interface that enables the user 140to register with the authentication system 200. During the registrationprocess, the authentication module 232 may generate a security key 204for a new user account associated with the user 140. In someembodiments, the security key 204 may be a private key that correspondsto a public key in an asymmetric cryptography system.

The process 300 then divides (at step 310) the security key intomultiple parts. For example, the authentication module 232 may dividethe security key 204 according to a scheme (e.g., the Shamir'sSecret-Sharing scheme), such that less than the total number of thedivided parts are needed to reconstruct the security key 204. Under theShamir's Secret-Sharing scheme, the security key 204 may be expressed asa polynomial having multiple coefficients. Each of the divided parts mayrepresent a point (e.g., a non-zero integer input to the polynomial, andthe corresponding integer output) associated with the polynomial, suchthat a number of the parts (less than the total number of divided parts)may be needed to reconstruct the polynomial (the security key 204). Insome embodiments, the authentication module 232 may determine the numberof parts desired or needed to reconstruct the security key 204 beforedividing the security key 204. For example, the authentication module232 may determine to divide the security key 204 into nine parts, whereany four parts are needed to reconstruct the security key 204. Theauthentication module 232 may then divide the security key 204 into nineparts 210 (210 a-210 i) under the Shamir's Secret-Sharing scheme usingthe determined parameters.

The process 300 then identifies (at step 315) electronic devicesassociated with the user account. For example, during the registrationprocess, the authentication application 216 may obtain identities of theelectronic devices from the user 104 to be associated with the useraccount. In some embodiments, the authentication application 216 mayhave access to the networking hardware (e.g., network cards, networkadaptors, antennas, etc.) of the user device 110. The authenticationapplication 216 may prompt the user 104 to access the electronic devicesto be associated with the user account via the authenticationapplication 116. The user 104 may have to indicate a network protocol(e.g., a Wi-Fi protocol, a Bluetooth protocol, a Zigbee protocol, awireless infrared communication protocol, etc.) and possibly a networkaddress associated with the electronic devices. In some embodiments, theauthentication application 116 may discover the electronic devices basedon the selected network protocol, and may enable the user 140 to selectfrom the discovered devices. As discussed herein, the electronic devicesmay be located in different locations (e.g., at home, at work, etc.).Thus, the authentication application 216 may enable the user 104 tocontinue to register new electronic devices to be associated with theuser account over a period of time (e.g., several days, etc.).

As new electronic devices are added to be associated with the useraccount, information related to the electronic devices are obtained andstored (e.g., in the database 202). The information of each electronicdevice may include a name (e.g., assigned by the user 104), a networkprotocol for connecting to the electronic device, and a network address.Furthermore, as the authentication application 216 accesses each of theelectronic devices, the authentication application 216 may allocate aspace in the non-transitory memory (e.g., a random access memory, aflash drive, etc.) of the electronic device for storing parts of one ormore security keys.

The authentication module 232 may also determine a trust score for eachelectronic device based on a security profile of the electronic device.For example, when the authentication application 216 accesses anelectronic device during the registration process, the authenticationapplication 216 may analyze a network connection type, a hardwareconfiguration, a software configuration, and a location (e.g., detectedbased information obtained from the location component 118 of the userdevice 110 when the electronic device is accessed via the user device110). For example, the trust score of an electronic device may begin as‘0,’ and as a network connection type, a hardware configuration, asoftware configuration, and/or the location that improves the securityof the electronic device is uncovered, the authentication system 200 mayincrease the trust score of the electronic device accordingly. In oneexample, the trust score of a smart watch 250 may be increased by theauthentication system 200 based on the authentication system 200determining that the latest security software has been installed on thesmart watch 250. The authentication system 200 may determine a trustscore of ‘20’ for the smart watch 250. In another example, the trustscore of the smart home entertainment system 246 is increased by theauthentication system 200 based on the authentication system 200determining that the connection type (e.g., a wireless infraredcommunication) of the smart home entertainment system 246 requires aline of sight with the connecting device and the smart homeentertainment system is fixed on a second story of a home of the user140. The authentication system 200 may determine a trust score of ‘30’for the smart home entertainment system 246. In yet another example, theauthentication system 200 may determine that the networked refrigerator248 can be connected externally via IP connection and a latest securitysoftware has not been installed on the networked refrigerator 248. Thus,the authentication system 200 may determine a low trust score of ‘10’for the networked refrigerator 248. Similarly, the authentication system200 may determine a trust score of ‘10’ for the networked light switch242 and a trust score of ‘20’ for the in-vehicle management system 244.

Thus, the authentication system 200 may determine different trust scoresfor the different electronic devices 242-250. In some embodiments, theauthentication system 200 may determine a distribution scheme for theelectronic devices 242-250 based on the trust scores of the electronicdevices 242-250. For example, the distribution scheme may provide fordistributing the parts 210 a-210 i in proportion to the trust scoresdetermined for the electronic devices. Thus, under the distributionscheme, the authentication system 200 may distribute one part of thesecurity key 204 to the networked light switch 242 (based on a trustscore of ‘10’), two parts of the security key 204 to the in-vehiclemanagement system 244 (based on a trust score of ‘20’), three parts ofthe security key 204 to the smart home entertainment system 246 (basedon a trust score of ‘30’), one part of the security key 204 to thenetworked refrigerator (based on a trust score of ‘10’), and two partsof the security key 204 to the smart watch 250 (based on a trust scoreof ‘20’).

At step 325, the divided parts of the security key are distributed amongthe electronic devices. For example, the authentication module 232 maytransmit the parts 210 of the security key 204 and the distributionscheme to the authentication application 216. In turn, theauthentication application 216 may distribute the parts 210 a-210 i tothe electronic devices 242-250 according to the distribution scheme. Forexample, the authentication application 216 may transmit the part 210 ato the networked light switch 242 via a Zigbee connection and store thepart 210 a in the allocated memory space of the networked light switch242. Similarly, the authentication application 216 may transmit theparts 210 b and 210 c to the in-vehicle management system 244 via aBluetooth connection and store the parts 210 b and 210 c in theallocated memory space of the in-vehicle management system 244, theauthentication application 216 may transmit the parts 210 d, 210 e, and210 f to the smart home entertainment system 246 via a wireless infraredcommunication connection and store the parts 210 d, 210 e, and 210 f inthe allocated memory space of the smart home entertainment system 246,the authentication application 216 may transmit the part 210 g to thenetworked refrigerator 248 via a Wi-Fi connection and store the part 210g in the allocated memory space of the networked refrigerator 248, andthe authentication application 216 may transmit the parts 210 h and 210i to the smart watch 250 via a Bluetooth connection and store the parts210 h and 210 i in the allocated memory space of the smart watch 250.

In some embodiments, more than one security key may be generated for theuser 104 during the registration process. For example, as disclosedherein, different security keys may be generated for the user account ofthe user 104, where each of the security keys corresponds to a differentrisk level. For example, the security key 204 may correspond to a mediumrisk level. The authentication system 200 may generate a security key206 that corresponds to a low risk level and a security key 208 thatcorresponds to a high risk level. In some embodiments, the differentsecurity keys 204-206 require different minimum numbers of parts inorder to be reconstructed. For example, since the security key 206corresponds to a low risk level, the authentication system 200 maydivide the security key 206 in a manner such that a lower number (lowerthan the number of parts required for the security key 204 to bereconstructed) (e.g., two parts) of parts are required for the securitykey 206 to be reconstructed. Since the security key 208 corresponds to ahigh risk level, the authentication system 200 may divide the securitykey 208 in a manner such that a higher number (higher than the number ofparts required for the security key 204 to be reconstructed) (e.g., sixparts) of parts are required for the security key 208 to bereconstructed. The parts may be transmitted and distributed among theelectronic devices 242-250 in the same manner as discussed above byreference to step 325. In some embodiments, the parts of the additionalkeys 206 and 208 may be distributed among the electronic devices 242-250under the same distribution scheme determined in the step 325. Theauthentication module 232 may also store information related to theparts being distributed to the electronic devices 242-250 (e.g., thenumber of parts stored in each of the electronic devices 242-250, theidentity of the parts being distributed to each of the electronicdevices 242-250, etc.) in the database 202.

Once the parts of the security keys 204-208 are distributed and storedin the electronic devices 242-250, the user 104 may be authenticated bythe authentication system 200 using the techniques disclosed herein.FIG. 4 illustrates the authentication system 200 authenticating a useraccording to one embodiment of the disclosure, and will be described byreference to FIG. 5, which illustrates a process 500 for authenticatinga user to the authentication system 200 according to an embodiment ofthe disclosure. In some embodiments, the process 500 may be performed bythe authentication system 200. The process 500 begins by receiving (atstep 505) a request for authenticating a user to access a user account.For example, the authentication module 132 may receive an authenticationrequest through the web server 134, the service application 138, and/orthe marketplace application 122 of the merchant server 120.

As discussed above, the user 104 may use the user device 110 to interactwith the web server 134, the service application 138, and/or themarketplace application 122 to perform various electronic transactionswith the merchant server 120 and/or the service provider server 130. Forsome of the electronic transactions, such as a login transaction, apayment transaction, or an onboarding transaction, the merchant server120 and/or the service provider server 130 may require the user 140 tobe authenticated before processing the requested transaction for theuser 140. For example, the user 140 may use the user interfaceapplication 112 of the user device 110 to log in to a user account withthe service provider server 130. In another example, the user may alsouse the user interface application 112 to submit a request for anelectronic payment transaction using the user account with the serviceprovider server 130. In yet another example, the user 140 may bebrowsing a website associated with the merchant server 120 and mayinitiate an online purchase of an item on the website. In someembodiments, the merchant server 120 may be affiliated with the serviceprovider server 130, and may transmit an authentication request to theservice provider server 130 for authenticating the user 140 for theonline purchase. Many other types of authentication requests arecontemplated as well in various embodiments—a user may need toauthenticate to any Internet-based application (e.g. web application)for example. A user may also need to authenticate to a security system,for example (e.g. gaining access to a particular area or building), ormore generally, any time a user may be required to provideidentifying/authorized credentials.

When the authentication system 200 receives an authentication request,the authentication system 200 may determine a risk level associated withthe authentication request. For example, when the authentication requestis associated with a login request, the authentication system 200 maydetermine a risk level for the login request based on a location of theuser device 110 when the login request was made (based on informationobtained from the location component 118 of the user device 110) and/ora number of failed login attempts made for the user account within apredetermined period of time (e.g., within the last 24 hours, etc.). Insome embodiments, the authentication system 200 may determine that therisk level of the login request is low when the user device is locatedat a location that is associated with the user 104 (e.g., the home ofthe user 104, the office of the user 104, the commute route between thehome and the office, etc.) and the number of failed login attempts madefor the user account is low (e.g., 0). On the other hand, theauthentication system 200 may determine that the risk level of the loginrequest is high when the number of failed login attempts made for theuser account within the predetermined period of time is high (e.g., 6times, 10 times, etc.).

When the authentication request is associated with an electronic paymenttransaction request, the authentication system 200 may determine therisk level of the payment transaction request based on an amountassociated with the electronic payment transaction request. For example,the authentication system 200 may determine that the risk level of thepayment transaction request is high when the amount associated with thepayment transaction request exceeds a first predetermined threshold(e.g., $500). The authentication system 200 may determine that the risklevel of the payment transaction request is low when the amountassociated with the payment transaction request is below a secondpredetermined threshold (e.g., $20), and may determine that the risklevel of the payment transaction request is medium when the amountassociated with the payment transaction request is between the first andsecond predetermined threshold.

The process 500 then determines (at step 510) a security key used forauthenticating the user based on the risk level determined for therequest. As discussed above, the user account of the user 104 may beassociated with multiple security keys, such as the security keys204-208, each associated with a different risk level and requires adifferent number of parts to be reconstructed. As such, based on therisk level determined for the authentication request, the authenticationsystem 200 may select the corresponding security key for theauthentication request. For example, the authentication request may beassociated with an electronic payment transaction in an amount of $250.As such, the authentication system 200 may determine that the risk levelof the request is medium, and select the security key 204 thatcorresponds to a medium risk level. As discussed above, the security key204 requires at least four parts in order to be reconstructed.

After determining the security key, the process 500 selects (at step515) two or more electronic devices for retrieving the parts of thesecurity key. For example, the authentication system 200 may select twoor more, but not all, of the electronic devices 242-250 associated withthe user account. In some embodiments, the authentication system 200 mayselect the two or more electronic devices based on a location and/or anactivity associated with the user 104. For example, when it isdetermined (based on information obtained from the location component118 of the user device 110) that the user is located at home, theauthentication system 200 may select electronic devices associated withthe home profile of the user account (e.g., the networked light switch242, the smart home entertainment system 246, the networked refrigerator248, etc.). Similarly, when it is determined that the user is located atthe office, the authentication system 200 may select electronic devicesassociated with the office profile of the user account, and when it isdetermined that the user is commuting (e.g., when it is determined thatthe user 104 is inside a vehicle along a regular commuting route), theauthentication system may select electronic devices associated with thecommuting profile.

In some embodiments, the authentication system 200 may select the two ormore electronic devices based on the risk level of the request and/orthe number of parts required to reconstruct the determined security key.In the example above where the security key 204 is determined for therequest, the authentication system 200 may determine that the securitykey 204 requires at least four parts to be reconstructed. As such, theauthentication system 200 may select the two or more electronic devicessuch that the total number of parts stored in the selected two or moreelectronic devices have at least four parts of the security key 204.

Furthermore, the authentication system 200 may also select the two ormore electronic devices such that at least two of the two or moreelectronic devices require different network protocols and/or networkconnectivity to connect to the electronic devices. Selecting electronicdevices that require different network protocols and/or networkconnectivity to connect enhances the security and effectiveness of theauthentication system 200 as it prevents false authentication of a usereven when one or more of the selected electronic devices may be accessedand/or taken over by an unauthorized user.

Referring to FIG. 4, the authentication system 200 determines that theuser 104 is at home based on information obtained from the locationcomponent 118 of the user device 110. Thus, the authentication system200 selects two or more electronic devices that are associated with thehome profile for authenticating the user 104. The authentication system200 may also look up the number of parts that are stored in each of theelectronic devices associated with the home profile to select the two ormore electronic devices such that the number of parts stored in theselected electronic devices equals to or more than the requiredthreshold (e.g., four) for reconstructing the security key 204. In thisexample, the authentication system 200 selects the networked lightswitch 242, the smart home entertainment system 246, and the networkedrefrigerator 248 for authenticating the user 104. As shown, the selectedelectronic devices store a total of five parts of the security key 204based on the information stored in the database 202—the networked lightswitch 242 stores one part of the security key 204, the smart homeentertainment system 246 stores three parts of the security key 204, andthe networked refrigerator 248 stores one part of the security key 204,which exceeds the required threshold (four parts) for reconstructing thesecurity key 204. In some embodiments, the authentication system 200selects the two or more electronic devices such that the number of partsstored in the selected devices is more than the required threshold forreconstructing the security key, anticipating that the user 104 may notbe able to connect to every one of the selected devices. In thisexample, since the security key 204 requires only four parts to bereconstructed, the user 104 may still be authenticated when theauthentication application 216 cannot connect to either the networkedlight switch 242 or the networked refrigerator 248.

The process 500 then retrieves (at step 520) the parts from the selectedelectronic devices. For example, the authentication module 232 mayinstruct the authentication application 216 to establish connectionswith the networked light switch 242, the smart home entertainment system246, and the networked refrigerator 248 based on their correspondingnetwork protocols and network addresses stored in the database 202. Oncethe connections with the selected electronic devices are established,the authentication application 216 may retrieve, from the non-transitorymemory space allocated for the authentication system 200 in the selectedelectronic devices, the parts of the security key 204. In this example,the authentication application 216 retrieves the part 210 a from thenetworked light switch 242 via a Zigbee connection, retrieves the parts201 d, 210 e, and 210 f from the smart home entertainment system 246 viaa wireless infrared communication connection, and retrieves the part 210g from the networked refrigerator via a Wi-Fi connection.

After retrieving the parts from the selected electronic devices, theprocess 500 reconstructs (at step 525) the security key based on theretrieved parts. In some embodiments, the authentication application 216transmits the retrieved parts 210 a, 210 d, 210 e, 210 f, and 210 g tothe authentication module 232 before the authentication module 232reconstructs the security key based on the retrieved parts. The process500 then determines (at step 530) whether the reconstructed security keymatches the security key that was originally assigned to the useraccount. For example, after receiving the parts 210 a, 210 d, 210 e, 210f, and 210 g from the authentication application 216, the authenticationmodule 232 may reconstruct the security key 204 based on the retrievedparts, and compare the reconstructed security key with the security key204 that was originally assigned to the user account to determinewhether they match.

However, to further enhance security of the authentication system 200(e.g., to avoid having the parts of the security key 204 transmittedover a network unnecessarily), the authentication application 216 ofsome embodiments may reconstruct the security key 204 based on theretrieved parts 210 a, 210 d, 210 e, 210 f, and 210 g. Theauthentication application 216 may use the security key 204 to sign(e.g., encrypt) the authentication request before transmitting thesigned authentication request to the authentication module 232. Thisway, the authentication system 200 avoids transmitting any sensitiveinformation over the network 160. As disclosed herein, in someembodiments, the security key 204 may be a private key that correspondsto a public/private key pair. The authentication module 232 may hold(e.g., store) the corresponding public key in the database 202. When theauthentication module 232 receives the signed authentication request,the authentication module 232 may verify the authenticity of thereconstructed security key (e.g., determining if the reconstructedsecurity key matches the security key 204) by decrypting the signedauthentication request using the corresponding public key.

If it is determined that the keys do not match, the process 500 denies(at step 535) the request. For example, the authentication module 232may send a signal to the application that submitted the authenticationrequest (e.g., the web server 134, the service application 138, and/orthe marketplace application 122) indicating a failed authentication. Inthe example illustrated above, the authentication request is associatedwith a login request received from the web server 134. Thus, theauthentication module 232 may send a signal to the web server 134indicating that the authentication has failed. The web server 134 maythen deny the login request based on the signal.

In some embodiments, instead of denying the request immediately, theauthentication system 200 may allow for multiple tries of authenticatingthe user 104, by selecting different combinations of electronic devices.For example, after failing to authenticate the user 104 based on thenetworked light switch 242, the smart home entertainment system 246, andthe networked refrigerator 248, the authentication system 200 mayattempt to authenticate the user 104 by selecting a differentcombination of electronic devices. In some embodiments, theauthentication system 200 may select the networked light switch 242, thenetworked refrigerator 248, and the smart watch 250 for authenticatingthe user 104 the second try, using the same techniques as describedherein. In some embodiments, the authentication system 200 may set apredetermined number of tries of authenticating the user 104 beforedenying the request. For example, the authentication system 200 may denythe authentication request after failing to authenticate the user 104twice using different combinations of electronic devices.

On the other hand, if it is determined that the keys match, the process500 processes (at step 540) the request. For example, the authenticationmodule 232 may send a signal to the application that submits theauthentication request (e.g., the web server 134, the serviceapplication 138, and/or the marketplace application 122) indicating asuccessful authentication. In the example illustrated above, theauthentication request is associated with an electronic paymenttransaction request received from the web server 134. Thus, theauthentication module 232 may send a signal to the web server 134indicating that the user 104 is authenticated. The web server 134 maythen grant and process the electronic payment transaction request basedon the signal.

In some embodiments, the authentication system 200 may periodicallyre-evaluate the electronic devices 242-250 and update the trust scoresand the distribution scheme. For example, after each authentication ofthe user (e.g., after successfully verifying the reconstructed securitykey), the authentication system may re-evaluate the selected electronicdevices, by accessing news regarding the electronic devices, and thehardware configurations and/or the software configurations of theelectronic devices. The authentication system 200 may determine whethernew security software update is available to the electronic devices andwhether the new security software update has been installed on theelectronic devices. For example, the authentication system 200 maydetermine that a latest version of the operating system that includes anupdated security patch is available for the networked light switch 242.While accessing the networked light switch, the authenticationapplication 216 may analyze the software configuration of the networkedlight switch 242 to determine whether the operating system has beenupdated to the latest version. If the authentication application 216determines that the operating system of the networked light switch 242has been updated to the latest version, the authentication system 200may increase the trust score of the networked light switch 242 from ‘10’to ‘20.’

The authentication system 200 may also receive news about hackingincidents to in-vehicle management systems similar to the in-vehiclemanagement system 244. Thus, based on the hacking incidents, theauthentication system 200 may reduce the trust score of the in-vehiclemanagement system 244 from ‘20’ to ‘10.’ The authentication system 200may then update the distribution scheme based on the updated trustscores of the electronic devices 242-250, and redistribute the parts ofthe security keys 204-208 among the electronic devices 242-250. In thisexample, based on the updated trust score, the authentication system 200may move the part 210 b from the in-vehicle management system 244 to thenetworked light switch 242 based on the updated distribution scheme.

In some embodiments, the security of the authentication system 200 maybe further enhanced by employing a key rotating scheme thatchanges/updates the security keys associated with the user 104. Forexample, the authentication system 200 may periodically replace thesecurity keys 204-208 with three different security keys. Theauthentication system 200 may use the same process as disclosed hereinto divide the security keys 204-208 into parts to correspond to thethree risk levels, such that a first new security key that correspondsto the low risk level requires two parts to be reconstructed, a secondnew security key that corresponds to the medium risk level requires fourparts to be reconstructed, and a third new security key that correspondsto the high risk level requires six parts to be reconstructed. Theauthentication system 200 may then distribute the parts of the newsecurity keys among the electronic devices 242-250 according to thedistribution scheme.

Thus, using the techniques disclosed herein, the authentication system200 provides a secure and convenient way for a user to be authenticated.Users may no longer need to remember lengthy passwords or utilizehardware devices for scanning biometric data of the users. Instead, auser device of the user may seamlessly perform the authentication of theuser by accessing electronic devices that are associated with the useraccording to various embodiments disclosed herein.

FIG. 6 is a block diagram of a computer system 600 suitable forimplementing one or more embodiments of the present disclosure,including the service provider server 130, the merchant server 120, theuser device 110, and the electronic devices 242-250. In variousimplementations, the user device 110 may include a mobile cellularphone, personal computer (PC), laptop, wearable computing device, etc.adapted for wireless communication, and each of the service providerserver 130 and the merchant server 120 may include a network computingdevice, such as a server. Thus, it should be appreciated that thedevices 110, 120, 130, and 242-250 may be implemented as the computersystem 600 in a manner as follows.

The computer system 600 includes a bus 612 or other communicationmechanism for communicating information data, signals, and informationbetween various components of the computer system 600. The componentsinclude an input/output (I/O) component 604 that processes a user (i.e.,sender, recipient, service provider) action, such as selecting keys froma keypad/keyboard, selecting one or more buttons or links, etc., andsends a corresponding signal to the bus 612. The I/O component 604 mayalso include an output component, such as a display 602 and a cursorcontrol 608 (such as a keyboard, keypad, mouse, etc.). The display 602may be configured to present a login page for logging into a useraccount or a checkout page for purchasing an item from a merchant. Anoptional audio input/output component 606 may also be included to allowa user to use voice for inputting information by converting audiosignals. The audio I/O component 606 may allow the user to hear audio. Atransceiver or network interface 620 transmits and receives signalsbetween the computer system 600 and other devices, such as another userdevice, a merchant server, or a service provider server via network 622.In one embodiment, the transmission is wireless, although othertransmission mediums and methods may also be suitable. A processor 614,which can be a micro-controller, digital signal processor (DSP), orother processing component, processes these various signals, such as fordisplay on the computer system 600 or transmission to other devices viaa communication link 624. The processor 614 may also controltransmission of information, such as cookies or IP addresses, to otherdevices.

The components of the computer system 600 also include a system memorycomponent 610 (e.g., RAM), a static storage component 616 (e.g., ROM),and/or a disk drive 618 (e.g., a solid state drive, a hard drive). Thecomputer system 600 performs specific operations by the processor 614and other components by executing one or more sequences of instructionscontained in the system memory component 610. For example, the processor614 can perform the risk analysis functionalities described hereinaccording to the processes 300 and 500.

Logic may be encoded in a computer readable medium, which may refer toany medium that participates in providing instructions to the processor614 for execution. Such a medium may take many forms, including but notlimited to, non-volatile media, volatile media, and transmission media.In various implementations, non-volatile media includes optical ormagnetic disks, volatile media includes dynamic memory, such as thesystem memory component 610, and transmission media includes coaxialcables, copper wire, and fiber optics, including wires that comprise thebus 612. In one embodiment, the logic is encoded in non-transitorycomputer readable medium. In one example, transmission media may takethe form of acoustic or light waves, such as those generated duringradio wave, optical, and infrared data communications.

Some common forms of computer readable media includes, for example,floppy disk, flexible disk, hard disk, magnetic tape, any other magneticmedium, CD-ROM, any other optical medium, punch cards, paper tape, anyother physical medium with patterns of holes, RAM, PROM, EPROM,FLASH-EPROM, any other memory chip or cartridge, or any other mediumfrom which a computer is adapted to read.

In various embodiments of the present disclosure, execution ofinstruction sequences to practice the present disclosure may beperformed by the computer system 600. In various other embodiments ofthe present disclosure, a plurality of computer systems 600 coupled bythe communication link 624 to the network (e.g., such as a LAN, WLAN,PTSN, and/or various other wired or wireless networks, includingtelecommunications, mobile, and cellular phone networks) may performinstruction sequences to practice the present disclosure in coordinationwith one another.

Where applicable, various embodiments provided by the present disclosuremay be implemented using hardware, software, or combinations of hardwareand software. Also, where applicable, the various hardware componentsand/or software components set forth herein may be combined intocomposite components comprising software, hardware, and/or both withoutdeparting from the spirit of the present disclosure. Where applicable,the various hardware components and/or software components set forthherein may be separated into sub-components comprising software,hardware, or both without departing from the scope of the presentdisclosure. In addition, where applicable, it is contemplated thatsoftware components may be implemented as hardware components andvice-versa.

Software in accordance with the present disclosure, such as program codeand/or data, may be stored on one or more computer readable mediums. Itis also contemplated that software identified herein may be implementedusing one or more general purpose or specific purpose computers and/orcomputer systems, networked and/or otherwise. Where applicable, theordering of various steps described herein may be changed, combined intocomposite steps, and/or separated into sub-steps to provide featuresdescribed herein.

The various features and steps described herein may be implemented assystems comprising one or more memories storing various informationdescribed herein and one or more processors coupled to the one or morememories and a network, wherein the one or more processors are operableto perform steps as described herein, as non-transitory machine-readablemedium comprising a plurality of machine-readable instructions which,when executed by one or more processors, are adapted to cause the one ormore processors to perform a method comprising steps described herein,and methods performed by one or more devices, such as a hardwareprocessor, user device, server, and other devices described herein.

1. (canceled)
 2. A system, comprising: a processor; a network interfacedevice; and a computer-readable medium having stored thereoninstructions that are executable to cause the system to performoperations comprising: receiving an authentication request,corresponding to a user of a first user device, to authenticate the userfor a requested access to a computing resource analyzing theauthentication request to determine a required multi-device securitytrust level for approving the authentication request, the multi-devicesecurity trust level corresponding to a plurality of different computingdevices associated with the user, wherein the plurality of differentcomputing devices include at least two different types of computingdevice; based on the required multi-device security trust level,obtaining first and second partial authentication responses for theauthentication request respectively from a first of the plurality ofdifferent computing devices and a second of the plurality of differentcomputing devices, wherein the first and second partial authenticationresponses include first and second security authentication informationthat is user-specific and issued only to the user, and wherein each ofthe first and second partial authentication responses is insufficient byitself to authenticate the user for the authentication request;calculating a total received security trust score for the authenticationrequest based on the first and second partial authentication responses,wherein the first partial authentication response contributes a firsttrust amount to the total received security trust score and the secondpartial authentication response contributes a second trust amount to thetotal received security trust score; based on the total receivedsecurity trust score, generating an authentication response for theauthentication request from the user; and transmitting the generatedauthentication response via the network interface device.
 3. The systemof claim 2, wherein generating the authentication response comprisesdetermining if the total received security trust score meets a requiredthreshold for the required multi-device security trust level andgenerating an approval authentication response if the required thresholdis met, and generating a rejection authentication response if therequired threshold is not met.
 4. The system of claim 2, wherein thefirst trust amount is different from the second trust amount.
 5. Thesystem of claim 2, wherein the operations further comprise: causing thefirst and second security authentication information to be distributedto the first and second different computing devices prior to receivingthe authentication request.
 6. The system of claim 2, wherein thecomputing resource comprises an Internet server configured to provideaccess to functionality of a user account of the user.
 7. The system ofclaim 2, wherein the operations further comprise: causing a prompt to beshown to the user on the first user device indicating an identity ofavailable devices of the plurality different computing devices that areusable to fulfill the authentication request.
 8. A method, comprising:receiving, by a computer system, an authentication request correspondingto a user of a first user device, wherein the authentication request isto authenticate the user for a requested access to a computing resource;analyzing the authentication request to determine a requiredmulti-device security trust level for approving the authenticationrequest, the multi-device security trust level corresponding to aplurality of different computing devices associated with the user,wherein the plurality of different computing devices include at leasttwo different types of computing device; based on the requiredmulti-device security trust level, the computer system receiving firstand second partial authentication responses for the authenticationrequest respectively from a first of the plurality of differentcomputing devices and a second of the plurality of different computingdevices, wherein the first and second partial authentication responsesinclude first and second security authentication information that isuser-specific, and wherein each of the first and second partialauthentication responses is insufficient by itself to authenticate theuser for the authentication request; calculating, by the computersystem, a total received security trust score for the authenticationrequest based on the first and second partial authentication responses,wherein the first partial authentication response contributes a firsttrust amount to the total received security trust score and the secondpartial authentication response contributes a second trust amount to thetotal received security trust score; based on the total receivedsecurity trust score, the computer system generating an authenticationresponse for the authentication request from the user; and the computersystem transmitting the generated authentication response via a networkinterface device of the computer system.
 9. The method of claim 8,wherein the operations further comprise: responsive to a userregistration request prior to the authentication request, registeringthe first and second different computing devices for authenticationusage for the user and assigning the first and second differentcomputing devices different trust amounts.
 10. The method of claim 8,wherein generating the authentication response comprises determining ifthe total received security trust score meets a required threshold forthe required multi-device security trust level and generating anapproval authentication response if the required threshold is met, andgenerating a rejection authentication response if the required thresholdis not met.
 11. The method of claim 8, further comprising: causing aprompt to be shown to the user on the first user device indicating anidentity of available devices of the plurality different computingdevices that are usable to fulfill the authentication request.
 12. Themethod of claim 8, wherein the computing resource comprises an Internetserver configured to provide access to functionality of a user accountof the user.
 13. The method of claim 8, wherein the generatedauthentication response is transmitted to the first user device.
 14. Themethod of claim 8, wherein the first different computing devicecomprises a smart appliance associated with a particular communicationnetwork corresponding to the user.
 15. The method of claim 8, whereinthe first and second partial authentication responses each compriserespective encrypted information decryptable only by the computersystem.
 16. A non-transitory computer-readable medium having storedthereon instructions that are executable by a computer system to causethe computer system to perform operations comprising: receiving anauthentication request, corresponding to a user of a first user device,to authenticate the user for a requested access to a computing resourceanalyzing the authentication request to determine a requiredmulti-device security trust level for approving the authenticationrequest, the multi-device security trust level corresponding to aplurality of different computing devices associated with the user,wherein the plurality of different computing devices include at leasttwo different types of computing device; based on the requiredmulti-device security trust level, obtaining first and second partialauthentication responses for the authentication request respectivelyfrom a first of the plurality of different computing devices and asecond of the plurality of different computing devices, wherein thefirst and second partial authentication responses include first andsecond security authentication information that is user-specific andissued only to the user, and wherein each of the first and secondpartial authentication responses is insufficient by itself toauthenticate the user for the authentication request; calculating atotal received security trust score for the authentication request basedon the first and second partial authentication responses, wherein thefirst partial authentication response contributes a first trust amountto the total received security trust score and the second partialauthentication response contributes a second trust amount to the totalreceived security trust score; based on the total received securitytrust score, generating an authentication response for theauthentication request from the user; and transmitting the generatedauthentication response via the network interface device.
 17. Thenon-transitory computer-readable medium of claim 16, wherein generatingthe authentication response comprises determining if the total receivedsecurity trust score meets a required threshold for the requiredmulti-device security trust level and generating an approvalauthentication response if the required threshold is met, and generatinga rejection authentication response if the required threshold is notmet.
 18. The non-transitory computer-readable medium of claim 16,wherein the first trust amount is different from the second trustamount.
 19. The non-transitory computer-readable medium of claim 16,wherein the computing resource comprises an Internet server configuredto provide access to functionality of a user account of the user. 20.The non-transitory computer-readable medium of claim 16, wherein theoperations further comprise: causing a prompt to be shown to the user onthe first user device indicating an identity of available devices of theplurality different computing devices that are usable to fulfill theauthentication request.
 21. The non-transitory computer-readable mediumof claim 16, wherein the generated authentication response istransmitted to the first user device.